Here you can search through the pages of this Namespace, their attachments and the files uploaded to the system.
Note: the results will only display the items you have permissions to read.
If at anytime you require assistance from CTS you must send in your FIX messages to API@ctsfutures.com . Our API support will not answer if the messages aren't delimited in a reasonable way for readability Session Initiation After a successful SSL connection, the T4 FIX API basic requirement is to have both the Initiator and Acceptor start with sequence number 1. The client will initiate the FIX [...]
This document outlines how to use the T4 FIX API 4.0 of Cunningham Trading Systems (CTS). The T4 FIX API conforms to the Financial Information eXchange (FIX) Protocol with minor improvements and customizations as presented herein. T4 FIX API applications cannot be run simultaneously with our frontend or other [...]
Order State and Execution The Execution Report message (MsgType=8) is used by the T4 FIX API to electronically notify execution events and order state changes. The following areas are covered by the T4 FIX API Execution Reports: * Confirm the receipt of an order. * Confirm changes to an existing order (i.e. accept, cancel requests and cancel replace requests). * Relay order status changes. * Relay trade information [...]
Multiple Traders Under an established FIX Session, multiple traders/users can be authenticated with the Trader Logon message. Trader Logons allow order routing for multiple traders under the same physical connection of the FIX Session. Trader Logons must follow the successful FIX Logon of the initial Master User. To enter Multi-Trader mode, the Master User must explicitly request it as an option on the FIX Logon with Tag 372 (RefMsgTypes) = UCG. Authentication Requirements [...]
Subscribing to Streaming Data The T4 FIX API provides (optional) subscriptions to streaming market data for all markets available in order routing. Market data is made available asynchronously and concurrently to order routing flow. The market data subscriptions are active during a FIX Session. They are initiated by Market Data Request messages (Tag 35=V). A Market Data Request is a general request for streaming of market data quotes on specific securities. Under the T4 [...]
Logon Traders Under an established FIX Session, multiple traders/users can be authenticated with the Trader Logon message. Trader Logons allow order routing for multiple traders under the the same physical connection of the FIX Session. Trader Logons must follow the successful FIX Logon of the initial Master User.
The FIX API responds to Trader Logons with the Trader Logon Response message. With this message, the FIX [...]
Logging out Traders Under an established FIX Session, multiple traders/users can be authenticated with the Trader Logon message. Trader Logons allow order routing for multiple traders under the the same physical connection of the FIX Session. Trader Logons must follow the successful FIX Logon of the initial Master User. A trader that has been successfully authenticated with a Trader Logon can be logged out by the Master User with a Trader Logout message. The FIX API [...]
Logging out Traders Under an established FIX Session, multiple traders/users can be authenticated with the Trader Logon message. Trader Logons allow order routing for multiple traders under the the same physical connection of the FIX Session. Trader Logons must follow the successful FIX Logon of the initial Master User. A trader that has been successfully authenticated with a Trader Logon can be logged out by the Master User with the Trader Logout message. Identifying the Trader The Trader Logout identifies [...]
Application Management Beyond order routing, the T4 FIX API provides additional functionalities to query and manage positions, orders and accounts. The Collateral Inquiry message (MsgTyp=BB) is the cornerstone of (non-routing) application management. If the requests are successful, Collateral Inquiries result in responses from the T4 FIX API server with Execution Reports , Collateral Reports or Security Definitions [...]
The T4 FIX API conforms to the Financial Information eXchange (FIX) Protocol with minor improvements and customizations. Documentation on FIX can be found at http://www.fixprotocol.org .
Requirements
To develop to the T4 FIX API, you need a dedicated SSL connection to a T4 FIX API [...]
[...] 34=2055|49=T4Example|56=T450=Account1|52=20130426-15:49:03.963|66=fnl-635025701439636585|1385=3|433=1|68=3|11=batch-1-635025701439636585|1=Account1|54=1|38=2|48=CME_20130600_ESM3|55=ES|207=CME_Eq|40=2|59=0|21=2|60=20130426-15:49:03.963|204=0|10101=157875|11=batch-2-635025701439636585|1=Account1|54=2|38=1|48=CME_20130600_ESM3|55=ES|207=CME_Eq|40=2|44=157900|59=0|21=2|60=20130426-15:49:03.963|204=0|10102=6|11=batch-3-635025701439636585|1=Account1|54=2|38=1|48=CME_20130600_ESM3|55=ES|207=CME_Eq|40=2|44=157900|59=0|21=2|60=20130426-15:49:03.963|204=0|10102=6|
[FIXNEWORDERLIST]
[MsgSeqNum] 34 = 2055
[SenderCompID] 49 = T4Example
[TargetCompID] 56 = T4
[SenderSubID] 50 = Account1
[SendingTime] 52 = 20130426-15:49:03.963
[ListID] 66 = fnl-635025701439636585
[ContingencyType] 1385 = 3 (SPARK)
[ListExecInstType] 433 = 1 (IMMEDIATE)
[TotNoOrders] 68 = 3
[ClOrdID] 11 = batch-1-635025701439636585
[Account] 1 = Account1
[Side] 54 = 1 (BUY)
[OrderQty] 38 = 2
[SecurityID] 48 = CME_20130600_ESM3
[Symbol] 55 = [...]
[...] is sent
Please note:
The Volume for the two components of the OCO should be specified as 0. The T4 FIX API works out the required OCO volumes based on the trigger order. The Side for the OCO components is specified as the opposite of the Trigger Side. For example, if the trigger order side is Buy, the components of the OCO would be Sells. if Contingency Type is set to AutoOCO (Tag 1385=2), prices for the two OCO orders are specified as a differential from the expected trade price of the trigger order. This [...]
Message Rejection FIX Session rule violations are manifested through the Reject message. The receipt of a Reject message signals a serious violation of FIX Session rules. Appropriate action must immediately be taken by the receiver of a Reject message. A rejected message may be retransmitted by the sending application if a correction is appropriate. The T4 FIX API can detect an extensive set of FIX session violations and [...]
[...] Requests To receive Security Definitions as responses to Security Definition Requests, the initiating FIX session Logon message must have Tag 372 (RefMsgType) set to "c" (i.e. Enable security definitions requests). Security definition requests that are not enabled will be rejected with a Security Definition containing a SecurityResponseType of Reject Security Proposal (Tag 323=5).
Definition of Securities The T4 FIX API provides a mechanism to list the securities available for [...]
Amending Working Orders The Order Cancel-Replace Request message (MsgType=G) is used by the T4 FIX API to electronically amend (i.e. revise) the replaceable fields of working orders. This message is used for all CTS strategy types including outright futures, futures options, spreads and multileg strategies. The instrument (for which the replace applies) is identified with the following tags: Tag 48 (SecurityID), Tag 55 (Symbol) Tag 207 (SecurityExchange) and Tag 167 (SecurityType). Options orders must also [...]
Submitting New Orders The New Order Single message (MsgType=D) is used by the T4 FIX API to electronically submit orders to an exchange for execution. This message is used for all strategy types including outright futures, futures options, spreads and multileg strategies. The instrument for which the order is submitted is identified with the following tags: Tag 48 (SecurityID), Tag 55 (Symbol), Tag 207 (SecurityExchange) and Tag 167 (SecurityType). Options orders must also include the Strike Price (Tag 202) [...]
Canceling Working Orders The Order Cancel Request message (MsgType=F) is used by the T4 FIX API to electronically cancel (i.e. pull) working orders. This message is used for all CTS strategy types including outright futures, futures options, spreads and multileg strategies. The instrument for which the cancel-request is submitted is identified with the following tags: Tag 48 (SecurityID), Tag 55 (Symbol) and Tag 207 (SecurityExchange). In addition to full market specification, all cancel requests must be [...]
[...] used to define the characteristics of exchanges, contracts and specific instruments (markets). The T4 FIX API returns this message as a result of queries performed with the Security Definition Request message. The Security definition message includes a complete description of securities by providing Exchange identifier, Contract identifier, Market identifier, pricing, minimum trading volumes, minimum price amount (including Variable Tick Tables), quantity leg ratios, buy/sell sides, put/call type, strikes, [...]
Describing Market Data The T4 FIX API supports streaming of market data with the Market Data Incremental Refresh message (Tag 35=X) alongside MarketData Snapshot messages (Tag 35=W). Market Data Incremental Refresh messages are responses to a Market Data Request message with a Subscription Request Type of Snapshot + Updates_Incremental (Tag 263=7).
They carry step-by-step changes to the depth book without having to transmit the complete depth information (for all requested book levels) as the Market Data [...]
A Flatten order can be used to flatten a current position regardless of what that position is. The T4 FIX API server figures out the volume and Buy/Sell parameters. If a position does not currently exist for the SecurityID (Tag 48) of the submitted flatten order, the order is rejected. A Flatten Order is entered with the New Order Single (Tag 35=D) message. Following are the most relevant tags to build a Flatten order.
Tag 40=F OrdType Specifier of Flatten Order Type
Tag 38 OrderQty Set to 0 to have [...]
[...] (administrative or application) are preceded by a Standard Header. In addition to providing the identification of FIX Session participants, the Standard Header identifies the Message Type (Tag 35), Message Length (Tag 9), Origination times (Tag 52 and Tag 122) and Message Sequence order (Tag 34). The Standard Header also offers additional information on FIX Session authentication, resent messages, duplicated messages and message routing and delivery. Standard Header Dictionary
Tag Field Name Req'd Comments 8 BeginString Y FIX.4.2 [...]
Describing Market Data The T4 FIX API support streaming of market data with the Market Data Snapshot message (Tag 35=W). The Market Data Snapshot messages are used as the response to a Market Data Request message. It can be used to transmit a list of quotes, a list of trades, index values, opening, closing, settlement, high, low, the trade volume or open interest for a security, or any combination of these. Market Data Snapshot messages sent as the result of a Market Data Request message will specify [...]
[...] Orders with Multiple Components: Batch Orders The New Order List message (MsgType=E) is used by the T4 FIX API to electronically submit (multiple-component) orders to an exchange for execution. Orders with multiple components are also known as Batch Orders. They are identified by its Contingency Type (Tag 1385). Batch orders can only contain (constituent) orders. The New Order List is built by specifying its ContingencyType (Tag 1385), target instrument (Tags 48, 55, 207, 167), account (Tag 1) and by adding each [...]
[...] Rejecting Attempts to Amend or Cancel Orders The Order Cancel Reject message (MsgType=9) is used by the T4 FIX API to electronically reject (failed) attempts to cancel or replace an order. Cancel Rejects are only generated for unsuccessful client side Order Cancel Request , Order Cancel Request or List Cancel Request messages. Unsolicited Cancel Rejects may also be generated for cancel rejects originated from non-T4-FIX-API [...]
Requesting the Status of an Order The Order Status Request message (MsgType=H) is used by FIX API clients to electronically interrogate the instantaneous state of an order. The OrderId Tag (37) identifies the specific order for which the Order Status Request is submitted. To pinpoint the order's instrument, the SecurityID (Tag 48) and Side (Tag 54) must also be specified. From the client's perspective, the queried order can further be identified with a verbose (# characters >= 12 and The Order Status Request message is responded to [...]
[...] Canceling Orders with Multiple Components The List Cancel Request message (MsgType=K) is used by the T4 FIX API to electronically cancel (i.e. pull) all components of contingent (Batch) orders (e.g. OCO, AutoOCO, Spark). The constituent order components must be in the working or suspended (held) state to result in a successful cancellation. This message is used for all CTS strategy types including outright futures, futures options, spreads and multileg strategies. Identifying the Order to be Canceled For list [...]
Session Termination The Logout message requests or indicates the termination of a FIX session. The logout initiator should wait for a response and/or confirmation to the logout condition. This will permit the counterparty to gently close its connection and honor a potential message gap-fill. If the T4 FIX API server initiates a Logout, an issuing physical disconnection will follow. When possible, the T4 FIX API [...]
A Queue Order submits an order to the T4 FIX API server for queueing (i.e. risk assessed, suspended and waiting for a request to activate). A Queue Order (Tag 10102=6) is queued with the New Order Single (Tag 35=D) message with an Activation Value of 0 (Tag 10103=0). Subsequently, a Queued Order is activated (to submit to the exchange) with the Cancel Replace Request (Tag 35=G) message with an Activation Value of -1 (Tag 10103=-1). Following are the most relevant tags to build a Queue order.
Tag 10102=6 [...]
[...] A Test Request message forces a response from the counterparty to acknowledge the continuation of FIX Session connectivity. Test requests can occur at any time during the FIX Session. When a test request is received, the party is obligated to respond to the Test Request message with a Heartbeat . Such heartbeat must also contain the TestRequestID (Tag 112) that originated in the Test Request message. Test Request messages also provide an opportunity to check for out-of-sequence conditions. It permits checking for the expected outgoing [...]
[...] 854=7). These reports are solely for user information only. By default, they are turned on for all FIX Connections. However, they can be suppressed from the FIX Session message flow by using a Logon MsgType of CB (Tag 372=CB).
Message Dictionary Tag Field Name Req'd Comments Standard Header Y MsgType = BA 909 CollInquiryID N Unique identifier for the collateral inquiry that generated this report. 908 CollRptID Y Unique identifier for this report. 910 CollStatus N Status of Entity carried by this report. 911 TotNumReports [...]